The contents of this document have been developed by CHX Security. CHX Security considers the contents of this document to be proprietary and business confidential information. This information is to be used only in the performance of its intended use. This document may not be released to another vendor, business partner or contractor without prior written consent from CHX Security. Additionally, no portion of this document may be communicated, reproduced, copied or distributed without the prior consent of CHX Security.

The contents of this document do not constitute legal advice. CHX Security’s offer of services that relate to compliance, litigation or other legal interests are not intended as legal counsel and should not be taken as such. The assessment detailed herein is against a fictional company for training and examination purposes, and the vulnerabilities in no way affect CHX Security external or internal infrastructure.

Inlanefreight Ltd. (“Inlanefreight” herein) contracted CHX Security to perform a Penetration Test of Inlanefreight’s externally and internally facing network to identify security weaknesses, determine the impact to Inlanefreight, document all findings in a clear and repeatable manner, and provide remediation recommendations.

CHX Security performed testing under a “black box” approach Thursday, February 29, 2024 without credentials or any advance knowledge of Inlanefreight’s externally or internally facing environment with the goal of identifying unknown weaknesses. Testing was performed from a non-evasive standpoint with the goal of uncovering as many misconfigurations and vulnerabilities as possible. Testing was performed remotely via a host that was provisioned specifically for this assessment. Each weakness identified was documented and manually investigated to determine exploitation possibilities and escalation potential. CHX Security sought to demonstrate the full impact of every vulnerability, up to and including internal domain compromise. If CHX Security was able to gain a foothold in the internal network, Inlanefreight allowed for further testing including lateral movement and horizontal/vertical privilege escalation to demonstrate the impact of an internal network compromise.

Table 1: Scope Details

During the external penetration test against the Inlanefrieght, CHX Security identified ten (10) high-risk findings one (1) low-risk, and one (1) medium-risk finding that threaten the confidentiality, integrity and availability of Inlanefreight’s information systems. One of these findings lead to the compromise of Inlanefreight’s internal network. Once CHX Security gained access to Inlanefreight’s internal network they were able to identify one (1) low-risk, one (1) medium-risk, and four (4) high-risk findings in the internal network.

For the external network the tester identified misconfigurations, multiple services that had high-risk vulnerabilities, as well an exposed services that appear to not be in use anymore.

One of the webservices exposed had a portion exposed that allowed the tester to move inside Inlanefreight’s internal network.  

Once the tester gained access to the internal network the tester found that overall, the Inlanefreight’s patch and vulnerability management was well maintained but that there were a couple critical patches that would have prevented further compromise of the network. Most of the flaws were related to misconfiguration and lack of hardening, with most falling under the categories of weak authentication and weak authorization.

One finding was a weak configuration involving service accounts that allows any authenticated user to steal a component of the authentication process that can often be guessed offline (via password “cracking”) to reveal the human-readable form of the account’s password. These types of service accounts typically have more privileges than a standard user, so obtaining one of their passwords in clear text could result in lateral movement or privilege escalation and eventually in complete network compromise. Fortunately, this issue can be corrected without the need for third-party tools. Microsoft’s Active Directory contains settings that can be used to minimize the risk of these resources being abused for the benefit of malicious users.

A webserver was found that the tester was able to find the credentials for on a share that they mounted once they were inside the internal network. The webserver was found to have a SQL console that the tester used to gain a command shell on the server which led to the complete compromise of the server that was hosting the webservice.

The tester also found shared folders with excessive permissions, meaning that all users in the internal network can access a considerable amount of data. While sharing files internally between departments and users is important to day-to-day business operations, wide open permissions on file shares may result in unintentional disclosure of confidential information. Even if a file share does not contain any sensitive information today, someone may unwittingly put such data there thinking it is protected when it isn’t. This configuration should be changed to ensure that users can access only what is necessary to perform their day-to-day duties.

CHX Security began all testing activities from the perspective of an unauthenticated user on the external network or from the internet.  Inlanefreight provided the tester with an IP address and domain name but did not provide additional information.  

During testing, CHX Security uncovered a total of ten (10) high-risk, one (1) medium-risk and one (1) low-risk findings that pose a material risk to Inlanefreight’s information systems. Two subdomains appear that they should not be publicly exposed, and one appears inactive. The below table provides a summary of the findings by severity level.

Table 2: Severity Summary

CHX Security gained access to the internal system through a command injection vulnerability and began testing activities from the perspective of an authenticated user (access gained from the external facing systems) on the network. Inlanefreight provided the tester with network ranges but did not provide additional information such as operating system or configuration information.  

Table 4: Severity Summary

CHX Security performed the following to fully compromise the INLANEFREIGHT.LOCAL domain.

1. 1.The tester used a command injection vulnerability found in the monitoring.inlanefreight.local domain to gain access as the user webdev on the host DMZ01. This user was a member of the (adm) group which has rights to read all the log files.  

2. 2.The tester found another user, srvadm, and their password shown in plaintext in a log.  

3. 3.The tester was able to use these credentials to gain persistence on the DMZ01 host by using the credentials with SSH.  

4. 4.Once connected via SSH the tester found that the user srvadm was allowed to run /usr/bin/openssl as the sudo user on the DMZ01 host.  

5. 5.Using these rights the tester was able to read the SSH of the root user on DMZ01 and fully compromise the DMZ01 host.  

6. 6.Using this access and Ligolo-NG the tester was able to setup the DMZ01 host as a pivot point to dig deeper into the Inlanefreight network.  

7. 7.Once the pivot was set up the tester was able to identify three more hosts on the network, during enumeration the hosts DEV01 (IP 172.16.8.20), DC01(IP 172.16.8.3) and MS01(IP 172.16.8.50) were identified. Notably DC01 was a domain controller.  

8. 8.Enumerating further the tester found DotNetNuke (DNN) running on the DEV01 host.  

9. 9.The tester also found a share that they were able to mount and read, as well as download files from.  

10. 10.There was a web.config file on the Shares that contained Administrator login credentials to the DNN webapp running on DEV01.  

11. 11.After logging into the DNN webapp the tester found a SQL Console that they were able to exploit to get command shell access on the host DEV01.  

12. 12.Using this access the tester found the user had SeImpersonate rights on the host.  

13. 13.With this in mind the tester was able to compromise the host with the “Print Nightmare” vulnerability. Using PrintSpoofer64.exe and nc.exe the tester was able to elevate their rights to the NT AUTHORITY\SYSTEM user, fully compromising the DEV01 host.  

14. 14.With the newly established rights on DEV01 the tester was able to dump the SAM database and get the Administrator’s hash as well as a plaintext password.  

15. 15.Dumping LSA again with CrackMapExec the tester was able to confirm that the plaintext password was a domain credential for the user hporter.  

16. 16.Hporter account had ForceChangePassword rights over the ssmalls user. 

17. 17.Using PowerView.ps1 the tester was able to change the password on the ssmalls user.  

18. 18.Using ssmalls user and going back through the shares found earlier the is a Backup.ps1 script that contains the user backupadm and their password.  

19. 19.Using the backupadm credentials the tester could connect to the MS01 Host. 

20. 20.Enumerating the MS01 host the tester found an unattend.xml file, with credentials for the user ilfserveradm who seems to not be a domain user.  

21. 21.Using ilfserveradm the tester was able to connect with RDP to MS01 and found that there was a service running, sysaxschedscp.exe that was exploitable to gain local administrator rights on the MS01 host.  

22. 22.Running lsadump with mimikatz the tester was able to find a password which upon querying the domain they discovered was for the account mssqladm that was being used for autologn. 

23. 23.Mssqladm has GenericWrite over the user ttimmons which was used to create a fake SPN and perform a targeted kerberoasting attack. 

24. 24.Back on the DEV01 machine the tester user PSCredential object to run commands as the mssqladm user where they used Set-DomainObject to set a fake SPN on the target account (ttimmons).  

25. 25.Back on the attack host the tester used GetUserSPN.py to perform a targeted Kerberoasting attack and got the users hash of their password.  

26. 26.Using Hashcat on this hash the tester was able to crack ttimmons password.  

27. 27.Checking BloodHound the tester found that ttimmons had GenericAll rights over the Server Admins group. 

28. 28.The Server Admins group appeared to have the ability to perform DCSync and obtain the NTLM password hash for any users in the domain.  

29. 29.Using PSCredential object again the tester added ttimmons to the Server Admins Group.  

30. 30.Finally, the tester used Secretsdump to DCSync all NTLM password hashes from the Domain Controller. 

31. 31.The tester than ran hashcat against all the password hashes and was able to find a few more passwords of users and to obtain the Administrator’s hash.  

32. 32.The tester was able to use the Administrator’s hash to connect to the Domain Controller host DC01.  

33. 33.Enumerating DC01 the tester found that the host had dual-homed NICs and found another network.  

34. 34.Scanning this network the tester found another host MGMT01 with an IP of 172.16.9.25 

35. 35.The tester also found SSH keys in a share that they could now access as the Administrator.  

36. 36.Using one of these SSH keys the tester was able to connect to the MGMT01 host after setting up a new pivot point with Ligolo-NG. 

37. 37.After connecting to MGMT01 the tester was able to discover that this was a Linux machine that was running an older kernel that was vulnerable to the dirtypipe exploit.  

38. 38.The tester was able to exploit this and gain root access to the MGMT01 host fully compromising it and fully compromising the Domain of Inlanefreight. 

After scanning the domain for subdomains the tester connected to monitoring.inlanefreight.local where they were redirected to a login page.

Figure 1: login screen

On this page the test used the hydra tool to test for passwords with the username admin and was able to find the credentials to login.

Figure 2: Using Hydra

Using this password the tester logged into the site where they found a monitoring console. The tester was able to bypass the filters in place on this console and gain a reverse shell into the host as the user webdev.

Figure 3: Using Burpsuite for filter bypass

Figure 4: Using Burpsuite for Filter Bypass

Figure 5: Running Command on attack host.

After gaining a reverse shell on the DMZ01 host the tester found they were a member of the adm group and could read logs. After reading some logs they were able to find cleartext credentials for the user srvadm.

Figure 6: Finding Cleartext Password in log.

The tester was able to use these credentials to login to the host as the user srvadm and discover that srvadm could run /usr/bin/openssl as the root user.

Figure 7: Logging in as srvadm User on DMZ01

With this knowledge the tester was able to read the root user’s SSH key to gain access to the host as the root user via SSH.

Figure 8: Finding SSH Key for root user.

Figure 9: Using SSH key to connect to DMZ01 as root user.

Next the tester set up ligolo-ng to use as a pivot from the attack machine to the 172.16.8.0/24 network.

Figure 10: Using Ligolo-NG to setup a tunnel.

Figure 11: Using Ligolo-NG to set up a tunnel.

Figure 12: Using Ligolo-NG to show ifconfig settings.

Next the tester scanned the subnet for any live hosts.

Figure 13: Running nmap scan on internal network.

The tester found three hosts that appeared to be live and did further scanning on them.

DEV01

Figure 14: Running nmap scan on internal network.

MS01

Figure 15: Running nmap scan on internal network.

DC01

Figure 16: Running nmap scan on internal network.

The tester found that DotNetNuke (DNN) was running on DEV01 (172.16.8.20)

Figure 17: DonNetNuke login page.

There was a login button for DNN

Figure 18: DonNetNuke login page.

Looking further into DEV01 the tester found that there was a share that they could mount and access files from. On this share they found a web.config file that had plaintext credentials for user Administrator.

Figure 19: Mounting NFS on DEV01

Figure 20: Finding Credentials in web.config file.  

The tester was able to use these credentials to log into the DNN webpage. Once logged in they found a SQL Console that they were able to use to run commands on the DEV01 host.

Figure 21: DonNetNuke sqlconsole.

Figure 22: DonNetNuke sqlconsole.

Figure 23: DonNetNuke sqlconsole.

Using this webshell the tester was able to gain a reverse shell connection on DEV01.

First they needed to add a listener to Ligolo-ng that was pointing to the internal IP on DEV01 of 172.16.8.120

Ligolo-NG command to add listener

listener_add --addr 0.0.0.0:1235 --to 127.0.0.1:9001

Figure 24: DonNetNuke sqlconsole base64 encoded reverse shell command.

Figure 25: Getting a shell on DEV01.

Next the tester, after checking the users rights, found that the user has SeImpersonatPrivilege. They were able to use these rights to escalate privileges to the nt authority\system.

Another listener was setup on the Ligolo-ng proxy

Figure 26: Adding a route to Ligolo-NG

Files were copied from the attack host to the DEV01 host using the Ligolo-ng proxy

Figure 27: Moving Files to DEV01

Another listener was setup with Ligolo-ng

Figure 28: Adding a listener to Ligolo-NG

A listener was setup on the attack host and after the command was ran a shell was gained as nt authority\system.

Figure 29: Exploiting PrintSpoofer64 to get an Admin Shell on DEV01

Figure 30: Getting a nt authority\system shell on DEV01.

From here the tester retrieved the contents of the SAM database and with the local administrator password hash.

Figure 31: Dumping the SAM files on DEV01.

The tester then moved this data back to their attack host,

Figure 32: Adding another listener to Ligolo-NG

Figure 33: Moving the SAM dump back to the attack host.

Next the tester used secretsdump to dump the SAM database and retrieve a set of credentials from LSA secrets. This also included a plaintext password

Figure 34: Running secrecsdump on the SAM files and finding a cleartext password.

The tester confirmed that credentials for Administrator work using crackmapexec

Figure 35: Confirming credentials for the Administrator user.

The tester confirmed that the plaintext password was for the user hporter.

Figure 36: Confirming password found was for hporter user.

The tester confirmed that the user hporter was a domain user with the reverse shell they had.

Figure 37: Confirming hporter user is a domain user.

The tester then moved SharpHound.exe over and ran it.

Figure 38: Running SharpHound.exe on the host.

After moving the BloodHound.zip file over to the attack host the tester uploaded the data into the bloodhound tool and looked at the rights the user hporter had, this showed that hporter had ForceChangePassword rights over the user ssmalls.

Figure 39: Checking that hporter has ForceChangePassword rights over ssmalls user.

After connecting as the user hporter to DEV01 the tester moved the PowerView tool over to DEV01 to force a password change on the ssmalls user.

Figure 40: Connecting to DEV01 with hporter user.

Figure 41: Changing password for ssmalls user.

Using the ssmalls user the tester enumerated shares and found that there was a Backup.ps1 script that had credentials for the user ilfserveradm.

Figure 42: Looking at shares with ssmalls.  

Figure 43: Viewing file found on share.

Connecting to the share with smbclient

Figure 44: Connecting to the share and downloading the script.

Figure 45: Finding credentials in the script file.

Using these credentials the tester was able to connect to the host MS01 as the user backupadm

Figure 46: Connecting to MS01 with backupadm and the password found.

The tester found an xml file on MS01 that had cleartext password for the ilfserveradm in it.

Figure 47: Finding a password for ilfserveradm user in the unattend.xml file.

Using these credentials the tester was able to RDP into the host.

Figure 48: Connecting to the host with ilfserveradm user.

Running lsadump with mimikatz the tester was able to find a password which upon querying the domain they discovered was for the account mssqladm that was being used for autologn.

After RDPing in and performing additional enumeration, the tester found some non-standard software installed in the C:\\Program Files (x86)\\SysaxAutomation

Figure 49: Running lsadump with mimikatz.

Figure 50: Running lsadump with mimikatz.

Mssqladm has GenericWrite over the user ttimmons which can be used to create a fake SPN and perform a targeted kerberoasting attack.

Figure 51: Checking mssqladmi has GenericWrite over user ttimmons.

Back on the DEV01 machine the tester used PSCredential object to run commands as the mssqladm user where the used Set-DomainObject to set a fake SPN on the target account (ttimmons).

Figure 52: Setting fake SPN account on ttimmons user.

Back on the attack host the tester used GetUserSPN.py to perform a targeted Kerberoasting attack and got the users hash of their password.

Figure 53: Kerberoasting attack on ttimmons.

Using Hashcat on this hash the tester was able to crack ttimmons password.

Figure 54: Running hashcat on ttimmons hash and finding their password.

Checking BloodHound the tester found that ttimmons had GenericAll rights over the Server Admins group.

Figure 55: Checking that ttimmons has GenericAll rights over Server Admins group.

The Server Admins group appeared to have the ability to perform DCSync and obtain the NTLM password hash for any users in the domain.

Figure 56: Checking that server admins group and DCSync to the DC.

Using PSCredential object the tester added ttimmons to the Server Admins Group.

Figure 57: Adding ttimmons to the server admins group.

Finally, the tester used Secretsdump to DCSync all NTLM password hashes from the Domain Controller including the Administrators hash.

Figure 58: DCSync and dumping the domains hashes.

The tester than ran hashcat against all the password hashes and was able to find a few more passwords of users.

Figure 59: Running Hashcat against the domain hashes.

This was Guest, ttimmons, mmertile and backupjob passwords that were found.

Next the tester was able to use the Administrators hash to connect to the Domain Controller host DC01.

Figure 60: Using the Administrators hash in a pass the hash attack to connect to the DC.

The tester then ran ipconfig and found the Domain Controller was dual-homed

Figure 61: Checking the DC to see if it is dual-homed.

Scanning the newly discovered network the tester found another host MGMT01 with an IP of 172.16.9.25

Figure 62: Scanning the new network found.

Figure 63: Scanning the new network found.

The tester also found SSH keys in  a share that they could now access since they were logged in as the Administrator.

Figure 64: Enumerating the DC and finding SSH keys.

Using one of these SSH keys the tester was able to connect to the MGMT01 host after setting up a new pivot point with Ligolo-ng

Figure 65: Setting up the double pivot point with Ligolo-NG

Figure 66: Starting a tunnel back to the attack host.

Figure 67: Connecting to MGMT01 via SSH key found on DC.

After connecting to MGMT01 the tester was able to discover that this was a linux machine that was running an older kernel that was vulnerable to the dirtypipe exploit.

Figure 68: Checking Kernel version on the MGMT01 host.

The tester was able to exploit this and gain root access to the MGMT01 host fully compromising it and fully compromising the Domain of Inlanefreight.

The tester moved the exploit to MGMT01

Figure 69: Moving the dirypipe exploit over to MGMT01

Then the tester ran the exploit and was able to gain root (administrator) rights on the machine.

Figure 70: Running dirtypipe and gaining root privileges on MGM01.

As a result of this assessment there are several opportunities for Inlanefreight to strengthen its internal network security. Remediation efforts are prioritized below starting with those that will likely take the least amount of time and effort to complete. Inlanefreight should ensure that all remediation steps and mitigating controls are carefully planned and tested to prevent any service disruptions or loss of data.

• Finding 1 – Verify the user's permission every time an access attempt is made. Implement this structurally using the recommended approach for your web framework.  

• Finding 2 – Implementing a defense in depth approach is key to make the upload process harder and more locked down to the needs and requirements for the service. Implementing multiple techniques is key and recommended, as no one technique is enough to secure the service. 

• Finding 3 – use verified and secured whitelist files and ignore everything else 

• Finding 4 – Set strong passwords (24+ character) passwords.  

• Finding 5 – Remove this site from the public domain, it appears to be a dev testing environment.  

• Finding 6 – Ensure that input goes through validation and is then escaped or sanitized. 

• Finding 7 – Sanitize and validate inputs 

• Finding 8 – Properly secure the gitlab instance, the /explore endpoint was open to browse without using any credentials.  

• Finding 9 – The safest way to prevent XXE is always to disable DTDs (External Entities) completely. 

• Finding 10 – The primary defense is to avoid calling OS commands directly. 

• Finding 11 – To protect against verb tampering, user input should be properly validated and sanitized and use appropriate security measures 

• Finding 12 – 

• Perform ongoing external network vulnerability assessments and password audits on all subdomains.  

• Perform periodic updates on the technologies in use for the subdomains.  

• Educate web developers on security hardening best practices compromise.  

• Keep a close record of site in use and remove any that are not being used anymore.  

• Finding 1 – Limit mounts and shares to users who absolutely need them.  

• Finding 2 – Set strong (24+ character) passwords on all SPN accounts. 

• Finding 3 – Patch the system. 

• Finding 1 – Secure files and shares that have passwords in them to Administrator access only.  

• Finding 2 – Transition from SPNs to Group Managed Service Accounts (gMSA) wherever possible. 

• Finding 3 – Implement an update policy to make sure patches are applied.   

• Finding 4 – Enhance the domain password policy.   

• Finding 5 – Perform a network file share audit. 

• Finding 6 – Enhance network logging and monitoring.    

• Finding 6 – Implement an enterprise endpoint detection & response solution. 

• Perform ongoing internal network vulnerability assessments and domain password audits.  

• Perform periodic Active Directory security assessments. 

• Educate systems and network administrators and developers on security hardening best practices compromise.  

• Enhance network segmentation to isolate critical hosts and limit the effects of an internal compromise. 

Each finding has been assigned a severity rating of high, medium, or low. The rating is based off of an assessment of the priority with which each finding should be viewed and the potential impact each has on the confidentiality, integrity, and availability of Inlanefreight’s data.

Table 5: Severity Definitions

Table 6: Exploitation Attempt Details

Table 7: Accounts Compromised

Table 8: Assessment Artifacts